I've accidentally committed pushes from another module. My apologizes, I am unsure of the proper way to remove these.

I've accidentally committed pushes from another module. My apologizes, I am unsure of the proper way to remove these.

No problem; git is really awesome, but not always super intuitive.

It looks like the unwanted commits are all related to your previous game overlay module.
I can think of 3 ways to fix it (in order of what I would try first)

1. Rebase and only bring in the changes for the new module
2. Open a new branch current with master, check the file you want out to it, commit the changes, then force-push the new branch with just the new module to your existing branch
3. Open a new branch that's current with master, then get merge --cherry-pick the changes you want.

Last, if you want, let me know and I am pretty sure I can fix it for you, but you might lose some commits. The only file you need here is modules/exploits/linux/local/cve_2020_8831_apport_symlink_privesc.rb, right?

Yes, I only want the files relevant to this module pushed. I just added the rebase let me know if it is sufficient.

Yes, I only want the files relevant to this module pushed. I just added the rebase let me know if it is sufficient.

Looks good! Let us know when you'd like us to review it.

@gardnerapp any update? Are you still working on this? Anything we can do to help?

Hello, I've been working on other things sorry for the delay. I wasn't sure where the symlink hijacking should occur, if you read my first comment I talk about it more there. Can't use /etc/cron.d because a cron with 777 perms won't execute, I was thinking about using /etc/init.d/ or ~/.bashrc. Not sure if you had any other ideas for where the file should execute, if you could point me in the right direction that would help. Thanks!

@gardnerapp any update? Are you still working on this? Anything we can do to help?

I'm going to try and finish this next week sorry for the delay just wanted to keep you updated.

I haven't forgotten about this. I'm able to create a root owned file w 777 perms named lock not sure what to do with it. Also I'm creating a container to help with testing.

@gardnerapp, I'm sorry I completely missed the requests.
If I understand correctly, this lets you write a root-permission file with an uncontrollable name? Is that correct?

@gardnerapp, I'm sorry I completely missed the requests. If I understand correctly, this lets you write a root-permission file with an uncontrollable name? Is that correct?

Yes sir, I've been working on other modules and have been stumped on this one for quiet some time. I've tried writing a cron but Ubuntu wont execute crons w 777 permissions, and I can't change the permissions because the file is owned by root. I've been thinking about going through the other places to persist but haven't gotten to it. Thanks for getting back to me.

Could we create a ~/.ssh/lock SSH private key and escalate w SSH? I've toyed around with /etc/rc.d and couldn't get anything to execute. Basically what I think we're looking for is anything that runs on boot or periodically on the system. We can make a check list and just go down that list until we hopefully find something.

My first thought was cron and something in rc.d, but if you've tried that, we'll need to dig a bit deeper.
When you tried rc.d, did you overwrite the executable, or a config/script?
I'm guessing that this does not have a read component so if we overwrite a config file, we can't save it, first?
I'd also be curious about replacing a .so file with a binary payload.

I've tossed this out to the greater hive mind, and they will likely have some thoughts, too.

#19815 may give you persistence ideas.

The exploit creates a file owned by root:root with the name of lock and 777 permissions. In order to avoid having to re-write the exploit for every single persistence directory I'm going to create this file manually. Every exploit will execute ~/home/ubuntu/exploit_test.sh which when executed will create /root/it_worked.

/etc/cron.d

~$ sudo touch /etc/cron.d/lock

~$ sudo chown root:root /etc/cron.d/lock && sudo chmod 777 /etc/cron.d/lock

~ $ cat exploit_test.sh 
touch /root/it_worked

$ cat /etc/cron.d/lock
 * * * * * /home/ubuntu/exploit_test.sh

 $ ls -la /root/it_worked 
ls: cannot access '/root/it_worked': No such file or directory

# Checking cron logs
$ cat /var/log/syslog
Aug 23 14:52:01 cron[533]: (*system*lock) INSECURE MODE (group/other writable) (/etc/cron.d/lock)

cron won't execute because of insecure perms :/

/etc/init.d

~$ ls -la /etc/init.d/lock
-rwxrwxrwx 1 root root 33 Aug 23 15:11 /etc/init.d/lock

$ cat /etc/init.d/lock
#! /bin/sh 
touch /root/it_worked

# rebooted system, let init scripts run
$ sudo ls -la /root/it_worked
ls: cannot access '/root/it_worked': No such file or directory

As ubuntu user I get permission denied when trying to run /etc/init.d/lock start. Stuck in a conundrum, need to use root to enable the start up script and trying to enable the service to get root. I have zero experience creating startup scripts in this directory and I am not sure if I did this properly, let me know.